In an environment where multiple users can concurrently access data, many systems currently hold a copy of each data item in a read-only entity bean. A single instance of each read-only bean is kept in memory so that transactions can access the read-only bean instead of hitting the database. In order to prevent the transactions from stepping on each other, the transactions are able to utilize an exclusive lock such that the transaction can lock that read-only bean for its own exclusive use during each method call on the bean. The current transaction can be suspended, a new transaction can be started, and the bean can be locked on behalf of the new transaction and the method on the bean called by the new transaction. One problem with this approach is that it requires a lot of overhead. It is necessary for the system to manage the suspending, resuming, and committing of transactions.
Exclusive locking, such as in an entity bean container, also limits scalability. Exclusive locking is undesirable in many applications because the data is read-only and many users wish to be able to view the data at the same time and not have to wait for earlier transactions to finish.